home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: seebs@solutions.solon.com (Peter Seebach)
- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
- Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
- Date: 7 Apr 1996 20:35:42 -0500
- Organization: Usenet Fact Police (Undercover)
- Message-ID: <4k9qhe$65r@solutions.solon.com>
- References: <JSA.96Feb16135027@organon.com> <dewar.828757752@schonberg> <danpop.828819479@rscernix> <dewar.828879781@schonberg>
- Reply-To: seebs@solon.com
- NNTP-Posting-Host: solutions.solon.com
-
- In article <dewar.828879781@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
- >Dan, you miss the point, of course read in Linux is compliant with the
- >ANSI standard, precisely because this standard does NOT specify any
- >required behavior for read, and permits the addition of such functions.
-
- No, it doesn't. Rather, it permits their addition only if no strictly
- conforming program can tell.
-
- Now, as it happens, Linux does do the right thing - if I define my own
- read(), I get *my* read any time I call read, so the implementation is
- conforming.
-
- If I got a conflict when I linked, the system would be violating ANSI.
-
- >How could you possibly claim that read could be non-compliant with ANSI
- >(something is either compliant or non-compliant, we do not have three
- >valued logic here).
-
- Yes we do. There are conforming, strictly conforming, and unconforming
- programs. And there are many things an implementation could do which
- are partially compliant, I'm sure. (Although "partially compliant"
- is not defined by ANSI.)
-
- -s
- --
- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
- C/Unix wizard -- C/Unix questions? Send mail for help. No, really!
- FUCK the communications decency act. Goddamned government. [literally.]
- The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
-